The filter buffered '-' lines in a pending_rm strbuf, deferring their
classification until a '+' or ' ' line revealed the post-image
position.  That buffering is unnecessary: a removal occupies no
post-image line, so it does not advance lno_in_postimage, and xdiff
emits removals before additions within a change.  A '-' therefore
arrives while lno_in_postimage already holds the index the following
'+'/' ' will occupy, and can be classified against the ranges as it
arrives.

The buffering also hid a bug: flush_hunk() drained pending_rm into the
range hunk whenever the hunk was active, even after lno_in_postimage
had advanced past the tracked range, so a deletion just after the
tracked function leaked into the patch.  Classifying each line as it
arrives removes the pending_rm buffer, the discard_pending_rm() helper,
three struct fields, and makes that bug impossible by construction.

Document the coordinate model: a block comment on struct
line_range_filter states it (the pre/post-image cursors, the 0-based
idx_in_postimage, removals classified by the following line) with a
worked example, and assert_hunk_counts() cross-checks the accumulated
hunk counts against the buffered lines.

Signed-off-by: Michael Montalbo <mmontalbo@gmail.com>

The synthetic hunk header that flush_hunk() builds emitted the begin
unadjusted for a side with no lines, naming the line at the change
instead of the line before it.  In t4211 this produced

	@@ -25,0 +18,9 @@

whose old side names a nonexistent line 25 in a 24-line file.  The
unified-diff convention that git diff and xdl_emit_hunk_hdr() follow is
to name the line just before the change (-24 here).

The convention dates to 12da1d1 (Implement line-history search (git
log -L), 2013-03-28), whose hand-rolled diff printer derived headers
from range arithmetic without that adjustment.  It special-cased only
file creation, so a creation matched git diff but an interior
insertion did not.  86e986f (line-log: route -L output through the
standard diff pipeline, 2026-03-17) reimplemented header emission but
preserved this convention, so the off-by-one is inherited rather than
new.  Blaming a changed fixture line can mislead here: for t4211's
vanishes-early that transition turned a "\ No newline at end of file"
modification (@@ -22,1 +24,1 @@) into a pure insertion (@@ -23,0 +24,1
@@), so that zero-count header is newly shaped by xdiff even though the
rule it follows predates it.

Apply the convention in a unified_begin() helper: when a side has no
lines, name the preceding line.  hunk.*_begin is seeded from xdiff's
hunk header, which already made this adjustment for a pure creation or
deletion (begin 0), so unified_begin() leaves a 0 alone.

Regenerate the two affected t4211 fixtures.  Every other hunk,
including file creations, is unchanged.

Signed-off-by: Michael Montalbo <mmontalbo@gmail.com>

builtin_diff() open-codes the line-range filter setup and teardown
around its xdi_diff_outf() call: zero the struct, point it at the
output callback, run the diff, flush the trailing range hunk, and
release the buffer.  The upcoming -L stat and check formats need the
same sequence.

Extract line_range_filter_init() for the setup and a
line_range_filter_diff() helper that runs an initialized filter through
xdi_diff_outf(), flushes the final range hunk, and releases it,
returning the latched error.  builtin_diff() now does init +
line_range_filter_diff(); the next two patches reuse them in
builtin_diffstat() and builtin_checkdiff() instead of repeating the
boilerplate.

No behavior change.

Signed-off-by: Michael Montalbo <mmontalbo@gmail.com>

Reuse the line_range_filter in builtin_diffstat() to produce
range-scoped statistics.  When a filepair carries line_ranges,
the filter wraps diffstat_consume() as its output callback,
forwarding only in-range lines for counting.  flush_hunk()
replays buffered content through diffstat_consume(), which
ignores synthetic @@ headers since it only counts '+' and '-'
lines.

Expand the output format allowlist in setup_revisions() to
accept --stat, --numstat, and --shortstat with -L.

Leave --dirstat out of the allowlist so it is rejected like any
other unsupported format.  It summarizes change as a per-directory
percentage, which is degenerate for the usual single tracked file
(always 100% of its directory) and, in its default changed-bytes
mode, would measure whole-file damage that ignores the tracked
range entirely.  --numstat already reports the exact range-scoped
per-file counts, so -L gains nothing from --dirstat.

Signed-off-by: Michael Montalbo <mmontalbo@gmail.com>

builtin_checkdiff() runs its own xdiff pass to detect whitespace
errors in newly added lines.  When -L is active, the check should
be scoped to the tracked line ranges rather than the whole file.

Reuse the line_range_filter to wrap checkdiff_consume(), the same
pattern already used for patch output and diffstat.  The filter
forwards only in-range lines for whitespace checking.

checkdiff reports the file line number of each error, which it
normally learns from the hunk header via checkdiff_consume_hunk().
The filter synthesizes its own hunk headers, so give it an optional
hunk callback and route checkdiff_consume_hunk() through it; this
sets the post-image position before the in-range lines are
replayed.  Without it the reported line numbers would count from
the start of the range hunk rather than the start of the file.

Add DIFF_FORMAT_CHECKDIFF to the -L output format allowlist in
setup_revisions() so that -L --check is accepted, and list --check
among the supported formats in the documentation.  Add tests
covering that whitespace errors are reported, scoped to the tracked
range, and labeled with the correct file line number.

Signed-off-by: Michael Montalbo <mmontalbo@gmail.com>